Home ›

Agrégateur de nouvelles

Printer-friendly versionPrinter-friendly version

L'IA générative et la prolétarisation de la pensée

Transcriptions - il y a 1 heure 17 min

ChatGPT fait-il de nous des abrutis ?
Voix off : IA qu'à m'expliquer
Grégoire Barbey : Mesdames et Messieurs, bonjour. Bienvenue dans IA qu'à m'expliquer, le podcast du Temps qui démystifie les intelligences artificielles. Pour cet épisode, j'ai reçu la philosophe Anne Alombert qui a publié tout récemment un petit livre sur la bêtise artificielle [De la bêtise artificielle ]. Dans cet ouvrage, elle propose une analyse au vitriol de ce qu'elle qualifie de propagande idéologique autour de (…)

- Transcriptions / , , ,

Appel à commentaire de la Commission "Vers des écosystèmes numériques ouverts européens"

Linuxfr.org - 13 janvier, 2026 - 19:18

La Commission européenne a lancé un appel à commentaires pour une nouvelle initiative stratégique intitulée « Vers des écosystèmes numériques ouverts européens », dont l’adoption est prévue au premier trimestre 2026. Motivée par les objectifs essentiels de souveraineté technologique et de cybersécurité, cette initiative vise à réduire la dépendance de l’Union européenne vis-à-vis des infrastructures numériques non européennes en renforçant le secteur open source européen. S’appuyant sur la stratégie 2020-2023 en matière de logiciels open source et complétant la future loi sur le développement du cloud et de l’IA, cette feuille de route vise à identifier les obstacles à l’adoption, à soutenir le développement des communautés et des start-ups open source, et à garantir que les technologies ouvertes dans des secteurs critiques tels que l’IA, le cloud et les applications industrielles soient développées et régies dans un cadre européen sûr, compétitif et transparent.

L’appel à commentaires suscite un certain enthousiasme de la communauté Open Source, avec 334 réponses moins d’une semaine après son ouverture. Cf. ces statistiques.

Continuez la lecture pour le détail des questions posées, quelques éléments de contexte et quelques éléments de réponses possible.

Sommaire Les 10 questions clefs

On peut identifier dans l’appel à commentaires une dizaine de questions, divisées en questions explicites (posées spécifiquement aux parties prenantes dans la consultation) et questions implicites (les problèmes sous-jacents que l’initiative cherche à résoudre).

Questions explicites

Ces questions sont répertoriées directement aux pages 3 et 4 afin que les parties prenantes puissent y répondre :

  1. Forces, faiblesses et obstacles : « Quelles sont les forces et les faiblesses du secteur open source de l’UE ? Quels sont les principaux obstacles qui entravent (i) l’adoption et la maintenance d’un open source de haute qualité et sécurisé ; et (ii) les contributions durables aux communautés open source ? »
  2. Valeur ajoutée : « Quelle est la valeur ajoutée de l’open source pour les secteurs public et privé ? Veuillez fournir des exemples concrets, y compris les facteurs (tels que le coût, le risque, la dépendance, la sécurité, l’innovation, entre autres) qui sont les plus importants pour évaluer la valeur ajoutée. »
  3. Mesures concrètes de l’UE : « Quelles mesures et actions concrètes peuvent être prises au niveau de l’UE pour soutenir le développement et la croissance du secteur open source de l’UE et contribuer à la souveraineté technologique et au programme de cybersécurité de l’UE ? »
  4. Priorités : « Quels domaines technologiques devraient être prioritaires et pourquoi ? »
  5. Compétitivité et résilience : « Dans quels secteurs une utilisation accrue de l’open source pourrait-elle conduire à une compétitivité et une cyber-résilience accrues ? »
Questions implicites

Voici les questions fondamentales qui motivent la nécessité de cette initiative pour la Commission, que l’on retrouve tout au long du contexte politique et de la définition du problème (pages 1-2) :

  1. Souveraineté : Comment l’UE peut-elle réduire sa dépendance vis-à-vis des pays tiers en matière d’infrastructures numériques et reprendre le contrôle de sa sphère numérique ?
  2. Passage à l’échelle : Comment l’UE peut-elle aller au-delà du financement de la recherche et de l’innovation pour soutenir réellement le passage à l’échelle, le déploiement industriel et la viabilité commerciale des innovations open source ?
  3. Administration publique : Comment le secteur public (États membres et régions de l’UE) peut-il mieux adopter les solutions open source afin d’éviter la dépendance vis-à-vis d’un fournisseur et d’accroître la transparence ?
  4. Durabilité : Comment l’UE peut-elle garantir que la valeur générée par les projets open source n’est pas uniquement exploitée en dehors de l’UE et que les développeurs européens ont accès au capital et aux infrastructures nécessaires à leur croissance ?
  5. Sécurité : Comment tirer parti des logiciels open source pour améliorer la transparence de la chaîne d’approvisionnement et la gestion des vulnérabilités en matière de cybersécurité ?
Bilan de la Stratégie Open Source 2020-2023 de la Commission européenne

Comme indiqué en intro, cette consultation a pour but (entre autres) de réviser la Stratégie Open Source 2020-2023 de la Commission européenne. Voici une analyse rapide de son bilan.

Cette stratégie se définissait par son slogan "Think Open". Le point clef, qu’on lui a reproché à son époque, est qu’elle était principalement une stratégie de transformation interne et culturelle (comment la Commission gère son informatique), plutôt qu’une stratégie de politique industrielle (comment l’Europe construit sa filière).

1. Forces, faiblesses et barrières
  • Analyse de la stratégie 2020-2023 : La stratégie identifiait correctement la force de l’Open Source comme levier d’innovation et de co-création.
  • Limite/Impact : Elle s’est concentrée sur les barrières administratives internes (simplifier la bureaucratie pour permettre aux fonctionnaires de contribuer au code). Elle a largement ignoré les barrières de marché (financement, concurrence déloyale des géants US) qui pèsent sur le secteur privé européen.
  • Bilan : Elle a réussi à lever des blocages juridiques internes, mais n’a eu que peu d’impact sur la fragmentation du marché européen.
2. Valeur ajoutée pour les secteurs public et privé
  • Analyse de la stratégie 2020-2023 : Elle a parfaitement théorisé la valeur ajoutée pour le secteur public : « Argent public, Code public », éviter le verrouillage propriétaire (vendor lock-in), et l’interopérabilité.
  • Limite/Impact : La stratégie visait à « montrer l’exemple » (lead by example). Cependant, l’impact réel sur le secteur privé est resté marginal, car la Commission a continué, paradoxalement, à dépendre massivement de solutions propriétaires (Microsoft 365) durant cette période, affaiblissant la portée de son message sur la valeur ajoutée de l’Open Source.
3. Mesures concrètes au niveau de l’UE
  • Analyse de la stratégie 2020-2023 : La mesure phare et le grand succès de cette stratégie a été la création du bureau de programme Open Source (OSPO) de la Commission ("OSOR"). Elle a aussi facilité la publication de logiciels comme EUSurvey ou LEOS.
  • Limite/Impact : Ces mesures étaient centrées sur l’institution (« Inner Source »). Il manquait des mesures de soutien financier direct à l’écosystème (type « Fonds Souverain ») qui sont demandées aujourd’hui.
4. Priorités technologiques
  • Analyse de la stratégie 2020-2023 : La stratégie mentionnait le Cloud, l’IA et la Blockchain de manière générique.
  • Limite/Impact : Elle manquait de ciblage stratégique. Elle traitait l’Open Source comme une méthode de travail, et non comme une brique de souveraineté pour des technologies critiques spécifiques (comme le demande aujourd’hui la Feuille de route sur le Cloud/Edge).
5. Compétitivité et résilience
  • Analyse de la stratégie 2020-2023 : Le document mentionnait la « souveraineté technologique » en introduction, citant Ursula von der Leyen.
  • Limite/Impact : L’approche est restée très « soft power » (influence par l’exemple). Elle n’a pas suffi à créer une résilience face aux chocs géopolitiques ou à l’extraterritorialité du droit américain (Cloud Act), car elle ne s’accompagnait pas d’une politique industrielle agressive.
6. Souveraineté (réduire la dépendance)
  • Bilan 2020-2023 : La stratégie posait le principe « Stay in control » (Garder le contrôle).
  • Réalité : C’est sans doute l’échec principal de la période. Malgré la stratégie, la dépendance de l’Europe aux hyperscalers non-européens s’est accrue (cf Asteres). La stratégie a sous-estimé la difficulté de migrer des infrastructures critiques vers de l’Open Source sans investissement massif dans des alternatives industrielles européennes.
7. Passage à l’échelle (upscaling)
  • Bilan 2020-2023 : La stratégie encourageait le partage et la réutilisation (Reuse).
  • Réalité : Le passage à l’échelle a été limité à des outils de niche (sondages, légistique). La stratégie n’a pas fourni les mécanismes pour transformer des projets Open Source européens en géants technologiques capables de rivaliser mondialement.
8. Administration publique (adoption)
  • Bilan 2020-2023 : Elle s’appuyait sur la Déclaration de Tallinn (2017).
  • Réalité : La création de l’OSPO a été un modèle positif suivi par certains États membres (ex: France - avec les limites que l’on sait, Allemagne, Pays-Bas…). Cependant, l’adoption reste très hétérogène. La stratégie manquait de “dents” (obligations contraignantes) pour forcer l’adoption des logiciels libres et des standards ouverts dans les marchés publics des États membres.
9. Durabilité (modèles économiques et maintenance)
  • Bilan 2020-2023 : La stratégie prévoyait que les développeurs de la Commission puissent contribuer “incidemment” aux projets externes.
  • Réalité : C’est une réponse insuffisante au problème de la maintenance des infrastructures critiques (le problème de « l’inconnu du Nebraska »). Le bénévolat ou les contributions ponctuelles de fonctionnaires ne remplacent pas un financement structurel des fondations et des mainteneurs, point soulevé par les experts (Doc 3).
10. Sécurité (supply chain)
  • Bilan 2020-2023 : Point fort de la stratégie via le programme EU-FOSSA (audits de sécurité financés par l’UE).
  • Réalité : La Commission a bien identifié que « Open Source = transparence = sécurité potentielle ». Cependant, l’approche était réactive (audit de l’existant). La nouvelle période (2024+) doit gérer les effets de bord du Cyber Resilience Act (CRA), qui a créé une insécurité juridique pour les développeurs Open Source que la stratégie 2020-2023 n’avait pas anticipée.
Conclusion de l’analyse

La stratégie 2020-2023 a été une étape culturelle nécessaire mais insuffisante.

  • Son mérite : Elle a légitimé l’Open Source au cœur de l’administration européenne (création de l’OSPO, changement de mentalité).
  • Sa limite : Elle est restée une stratégie informatique interne (« Comment la Commission utilise le logiciel libre ») et non une stratégie politique (« Comment l’Europe utilise le logiciel libre pour sa souveraineté »).

Nous appelons donc à ce que la nouvelle initiative (2026) opère ce basculement : passer de l’Open Source comme « bonne pratique administrative » à l’Open Source comme « arme de souveraineté industrielle ».

Eléments de réponse

La Feuille de route thématique « La voie du logiciel libre vers la souveraineté numérique et la compétitivité de l’Union européenne » rédigée par un groupe d’experts (dont je (NdM: Stefane Fermigier) faisais partie) de l’Alliance européenne pour les données industrielles, l’Edge et le Cloud, et publiée par la Commission en juillet 2025 fournit un certain nombre d’éléments de réponses aux questions ci-dessus. Avec 70 propositions il y a évidemment de quoi « faire son marché ». Voici quelques éléments de réponse possibles extraits du document.

1. Forces, faiblesses et obstacles du secteur open source de l’UE

Forces :

  • Engagement politique et financier : l’Europe a démontré son engagement à travers le financement de la recherche (Horizon Europe, Digital Europe) et des cadres politiques (Data Act) qui favorisent la transparence (*p. 16-17).
  • Écosystème en pleine croissance : on observe une expansion des fournisseurs européens de cloud et d’edge open source proposant des alternatives conformes au RGPD, ainsi que de grands consortiums multipartites (bien qu’ils soient confrontés à des défis) et des collaborations avec des instituts de recherche (p. 18-19).
  • Cadres spécialisés : L’Europe assiste à l’adoption croissante de cadres open source spécialisés dans l’IoT dans des secteurs tels que l’industrie manufacturière et l’énergie (p. 19).

Faiblesses :

  • Domination des technologies non européennes : le marché est fortement influencé par les technologies propriétaires et les hyperscalers non européens, en particulier dans les domaines du cloud, de l’edge computing et des technologies de conteneurisation (p. 20).
  • Fragmentation : Les initiatives nationales sont souvent fragmentées et manquent de coordination au niveau européen (p. 17).
  • Problèmes de gouvernance : De nombreux projets, même ceux qui bénéficient de contributions européennes, sont gérés par des entités non européennes (par exemple, la Linux Foundation), ce qui peut entraîner un décalage par rapport aux intérêts européens (p. 26).

Principaux obstacles :

(i) À l’adoption et à la maintenance :

  • Obstacles à l’interopérabilité : Il existe un manque de « normes véritablement ouvertes » universellement adoptées et développées par des entités européennes. Cela entraîne une complexité d’intégration et des frictions entre les outils propriétaires et les outils open source (p. 24).
  • Sensibilisation du marché et discours : les PME et les entreprises hésitent en raison d’idées fausses sur la complexité et le soutien, souvent alimentées par les discours marketing des fournisseurs dominants non européens (p. 25).
  • Pénurie de compétences : l’offre de professionnels maîtrisant les technologies open source européennes, l’orchestration du cloud et la cybersécurité est insuffisante (p. 25-26).

(ii) Vers des contributions durables :

  • Contraintes en matière de ressources et de financement : De nombreux projets essentiels dépendent de contributions bénévoles et de financements sporadiques. Le paysage actuel favorise souvent les grands projets bien établis, laissant les petites initiatives européennes innovantes sous-financées (p. 24-25).
2. Valeur ajoutée pour les secteurs public et privé

Le document identifie la valeur ajoutée dans plusieurs dimensions, en se concentrant principalement sur la souveraineté numérique, la sécurité, la résilience économique et la durabilité.

Exemples concrets et facteurs :

  • Administration publique :
    • Souveraineté et contrôle : l’adoption de l’open source européen permet aux institutions de garder le contrôle sur le traitement et le stockage des données, réduisant ainsi leur dépendance vis-à-vis de fournisseurs étrangers soumis à des lois extraterritoriales (par exemple, la section 702 de la loi américaine FISA).
    • Sécurité et conformité : la transparence totale du code permet un audit rigoureux, garantissant la conformité avec les directives RGPD et NIS.
    • Coût et transparence : cela réduit les coûts d’approvisionnement/de licence et favorise la confiance du public grâce à des systèmes transparents (p. 50).
  • Secteur privé (général et PME) :
    • Innovation : cela réduit les barrières à l’entrée pour les PME, leur permettant d’être compétitives en tirant parti d’une infrastructure abordable et personnalisable. Cela accélère les cycles de développement grâce à l’innovation collaborative (p. 13).
    • Réduction des risques : cela évite la dépendance vis-à-vis d’un fournisseur associée aux normes propriétaires (p. 11).
  • Fabrication (industrie 4.0) :
    • Efficacité opérationnelle : permet une maintenance prédictive et une surveillance en temps réel.
    • Flexibilité : les normes ouvertes permettent l’intégration transparente de nouvelles technologies dans les systèmes existants, évitant ainsi la dépendance (p. 51).
3. Mesures et actions concrètes au niveau de l’UE

La feuille de route propose des actions (70 au total) réparties en cinq piliers afin de soutenir le secteur et de contribuer à la souveraineté et à la cybersécurité, notamment :

1. Développement technologique :

  • Normes : définir et imposer une « interopérabilité exécutoire » basée sur des normes véritablement ouvertes pour toutes les infrastructures numériques financées par l’UE (p. 28-29).
  • Financement : créer un « Fonds européen pour la souveraineté open source » (NB : EOSSF → EU-STF) pour les projets fondamentaux (p. 30).
  • Architectures de référence : développer des implémentations de référence spécifiques à chaque secteur (par exemple, pour les soins de santé ou l’énergie) (p. 30-31).

2. Développement des compétences :

  • Formation et certification : Lancer des programmes de certification pour la maîtrise de l’open source européen et financer des ateliers de formation axés sur l’industrie (p. 32-33).
  • Éducation : Intégrer les principes de l’open source dans les programmes d’études STEM et créer des centres d’excellence dans les universités (p. 34).

3. Pratiques d’approvisionnement :

  • Politique : Adopter des politiques « Fonds publics, code public, open source d’abord, préférence européenne » (p. 36).
  • Lignes directrices : Créer des guides d’évaluation pratiques et un répertoire de solutions européennes recommandées à l’intention des responsables des marchés publics (p. 37-38).

4. Croissance et investissement :

  • Plateforme d’investissement : créer une « plateforme européenne d’investissement dans l’open source » (EOSIP) afin de consolider les informations sur le financement (p. 41).
  • Image de marque : lancer une initiative de promotion de l’image de marque afin de mettre en avant la sécurité et la souveraineté des projets européens (p. 43).

5. Gouvernance :

  • Analyse de sécurité : donner la priorité aux évaluations de vulnérabilité pour les projets critiques et collaborer avec les agences de cybersécurité (p. 45).
  • Comité consultatif : former un comité consultatif européen sur l’open source afin de superviser le financement et l’orientation (p. 47).
4. Domaines technologiques prioritaires

La feuille de route donne explicitement la priorité aux technologies Cloud, Edge et Internet des objets (IoT).

Pourquoi ces technologies sont-elles prioritaires ?

  • Épine dorsale de l’infrastructure : ces technologies constituent « l’épine dorsale de l’infrastructure numérique moderne » et sont essentielles pour la sécurité nationale et économique (p. 10).
  • Dépendance actuelle : l’Europe est fortement dépendante des hyperscalers non européens dans ces domaines, ce qui pose des risques en matière de confidentialité des données, de sécurité nationale et de résilience opérationnelle (p. 10).
  • Tendances émergentes : certains sous-domaines sont mis en avant comme étant essentiels pour la souveraineté future :
    • Edge Computing : essentiel pour réduire la latence et assurer la souveraineté des données (en gardant le traitement proche de la source) (p. 20).
    • Conteneurisation/Orchestration : critiques pour l’évolutivité, mais actuellement dominées par des entités non européennes (p. 20).
    • IA/apprentissage automatique : l’intégration de l’IA dans les appareils périphériques, pour l’IoT industriel et les systèmes autonomes (p. 20).

NB: d’autres domaines prioritaires peuvent également être mis en avant, en dehors de la feuille de route, notamment le collaboratif (bureautique).

5. Secteurs pour une compétitivité et une cyber-résilience accrues

Le document identifie les secteurs suivants dans lesquels l’open source peut stimuler la compétitivité et la résilience (p. 50-53) :

  • Administration publique : renforce la confiance, la souveraineté des données et réduit les coûts.
  • Fabrication (industrie 4.0) : améliore l’efficacité de la production, réduit les déchets et empêche la dépendance vis-à-vis d’un fournisseur.
  • Santé : sécurise les données sensibles des patients, permet l’interopérabilité entre les systèmes (par exemple, les dossiers médicaux électroniques) et accélère la recherche médicale.
  • Énergie : optimise la gestion de l’énergie (réseaux intelligents), intègre les énergies renouvelables et réduit la consommation énergétique des centres de données.
  • Autres secteurs : transports, agriculture, finance, éducation, villes intelligentes et industrie spatiale (en particulier l’analyse des données d’observation de la Terre) (p. 53).
Références Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Marseille: Réunion d'information Installation Linux, Le mercredi 14 janvier 2026 de 18h00 à 19h00.

l'Agenda du Libre - 13 janvier, 2026 - 12:55

Môtiers: Samedi du Libre, Le samedi 17 janvier 2026 de 09h00 à 16h30.

l'Agenda du Libre - 12 janvier, 2026 - 19:22

Journée logiciel libre / Install party.

Ouvert à tout le monde.

Projets Libres saison 4 épisode 9 : le référentiel national des bâtiments (RNB)

Linuxfr.org - 12 janvier, 2026 - 15:25

Pour ce premier épisode de 2026, nous parlons d'Open Data

Agenda du Libre pour la semaine 3 de l’année 2026

Linuxfr.org - 12 janvier, 2026 - 14:38

Calendrier Web, regroupant des événements liés au Libre (logiciel, salon, atelier, install party, conférence), annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 48 événements (France : 46, Internet : 2, Québec : 1) est en seconde partie de dépêche.

Sommaire

Revue de presse de l’April pour la semaine 2 de l’année 2026

Linuxfr.org - 12 janvier, 2026 - 14:29

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.

Libérer - Délivrer, un escape game pour découvrir les logiciels libres

Transcriptions - 12 janvier, 2026 - 13:50

Aller à la rencontre du grand public pour lui présenter les logiciels libres n'est pas toujours aisé. J'ai cherché une méthode ludique pour intéresser celui des Geek Faëries et j'en ai conclu qu'un jeu de logique pouvait être une bonne idée. Venez découvrir comment mon cerveau a élaboré ce jeu, comment je l'ai fait tester, quels outils j'ai utilisés et le résultat final.
Bonjour à toustes. Merci d'être là. Je suis venue pour parler d'un jeu de société qui s'appelle Libérer, Délivrer. (…)

- Transcriptions / , , , , ,

Montpellier: Rendez-vous | Quadrapéro, Le jeudi 15 janvier 2026 de 20h20 à 21h00.

l'Agenda du Libre - 12 janvier, 2026 - 05:26

Afin de se rencontrer, d’échanger et de faire plus ample connaissance, Montpel’libre lance de nouvelles rencontres surnommées les Quadrapéros. C’est l’occasion pour les neurones de toute part de se réunir physiquement pour discuter, échanger et partager un verre et de quoi grignoter.

Ce rendez-vous est «hybriditiel» ou «hybridiciel», c’est à dire qu’il sera à la fois en présentiel et en distanciel.

Les Quadrapéros auront lieu tous le 3e jeudi de chaque mois. Ils sont l’occasion de discussions informelles d’une part et de discussions plus sérieuses sur les différents thèmes d’importance et les différentes actions et campagnes en cours.

Tout le monde est invité aux Quadrapéros, qu’on soit contributeur ou contributrice de longue date, simple intéressé par les sujets que défend la Quadrature, ou nouvel arrivant cherchant à participer davantage. N’hésitez pas à amener vos amis et à leur faire découvrir La Quadrature et Montpel’libre.

Peuvent être aussi abordées des questions sur Les exégètes amateurs ou Open Law.

Les discussions de ce mois-ci se porteront sur l'actualité de moment.

Entrée libre et gratuite sur inscription. Une simple adhésion à l’association est possible.

Tramway lignes 1, 2, 3 et 4, arrêts Gare Saint-Roch
GPS Latitude: 43.60285 | Longitude: 3.87927
Carte OpenStreetMap

https://montpellibre.fr/fiches_activites/Fiche_022_Montpellibre_Rendez-vous_Quadrapero.pdf

Montpellier: Rendez-vous | FSFapéro, Le jeudi 15 janvier 2026 de 19h40 à 20h20.

l'Agenda du Libre - 12 janvier, 2026 - 05:26

Afin de se rencontrer, d’échanger et de faire plus ample connaissance, Montpel’libre lance de nouvelles rencontres surnommées les FSFapéros. C’est l’occasion pour les neurones de toute part de se réunir physiquement pour discuter, échanger et partager un verre et de quoi grignoter.

Ce rendez-vous est «hybriditiel» ou «hybridiciel», c’est à dire qu’il sera à la fois en présentiel et en distanciel.

Les FSFapéros auront lieu tous le 3e jeudi de chaque mois. Ils sont l’occasion de discussions informelles d’une part et de discussions plus sérieuses sur les différents thèmes d’importance et les différentes actions et campagnes en cours.

Tout le monde est invité et peut venir aux FSFapéros, qu’on soit contributeur de longue date, simple intéressé-e par les sujets que défend la Free Software Foundation Europe, ou nouvel-le arrivant-e cherchant à participer davantage. N’hésitez pas à amener vos amis et à leur faire découvrir la Free Software Foundation, et Montpel’libre.

Peuvent être aussi abordées des questions sur Les exégètes amateurs ou Open Law.

Les discussions de ce mois-ci se porteront sur l'actualité de moment.

Entrée libre et gratuite sur inscription. Une simple adhésion à l’association est possible. Rejoindre le groupe Montpel’libre sur Telegram S’inscrire à l’Infolettre de Montpel’libre.

Tramway lignes 1 et 3, arrêts Port-Marianne et Rives du Lez
GPS Latitude: 43.603095 | Longitude: 3.898166
Carte OpenStreetMap

https://montpellibre.fr/fiches_activites/Fiche_021_Montpellibre_Rendez-vous_FSF-FSFE_Apero.pdf

Montpellier: Rendez-vous | Aprilapéro, Le jeudi 15 janvier 2026 de 19h00 à 19h40.

l'Agenda du Libre - 12 janvier, 2026 - 05:26

Un apéro April consiste à se réunir physiquement afin de se rencontrer, de faire plus ample connaissance, d’échanger, de partager un verre et de quoi manger mais aussi de discuter sur l’actualité et les actions de l’April.

Ce rendez-vous est « hybriditiel » ou « hybridiciel », c’est à dire qu’il sera à la fois en présentiel et en distanciel.

Un apéro April est ouvert à toute personne qui souhaite venir, membre de l’April ou pas. N’hésitez pas à venir nous rencontrer.

Les apéros April ont lieu chaque mois à Paris, Marseille et à Montpellier.

Régulièrement Montpel’libre relaie et soutient les actions de l’April. De nombreux Apriliens ont par ailleurs rejoints les rangs de Montpel’libre, lors d’événements tels que les Apéros April, l’AprilCamp ou les Rencontres Mondiales du Logiciel Libre qui ont eu lieu à Montpellier et bien sûr de nombreux Montpel’libristes sont adhérents de l’April.

Nous vous invitons donc à venir nous rejoindre dans une ambiance conviviale, à partager cet apéro, chacun porte quelque chose, boissons, grignotages... et on partage.

Les discussions de ce mois-ci se porteront sur l'actualité de moment.

Entrée libre et gratuite sur inscription. Une simple adhésion à l’association est possible. Rejoindre le groupe Montpel’libre sur Telegram S’inscrire à l’Infolettre de Montpel’libre.

Tramway lignes 1 et 3, arrêts Port-Marianne et Rives du Lez
GPS Latitude : 43.603095 | Longitude : 3.898166
Carte OpenStreetMap

https://montpellibre.fr/fiches_activites/Fiche_020_Montpellibre_Rendez-vous_Aprilapero.pdf

Mauguio: Permanence | Linuxerie | GNU/Linux et Logiciels Libres, Le mercredi 14 janvier 2026 de 17h00 à 19h00.

l'Agenda du Libre - 12 janvier, 2026 - 05:25

Venez découvrir GNU/Linux et vous faire aider pour l’installation et à la prise en main, dans différents lieux de l’Hérault.

L’équipe de Montpel’libre vous propose une permanence Logiciels Libres: discussions libres et accompagnement technique aux systèmes d’exploitation libres pour vous aider à vous familiariser avec votre système GNU/Linux au quotidien.

Le contenu de l’atelier s’adapte aux problèmes et aux questionnements des personnes présentes avec leurs ordinateurs, qu’ils soient fixes ou portables. Il permet ainsi l’acquisition de nouvelles compétences nécessaires à une autonomie numérique certaine, au rythme de chacun.

Les personnes débutantes souhaitant découvrir GNU/Linux et apprendre à l'installer et à s'en servir. Les personnes plus expérimentées à la recherche d'une aide technique pour résoudre des problèmes spécifiques. Cet atelier s'adresse à un public adulte et capable d'utiliser un ordinateur.

Possibilité d'installer les variantes d'Ubuntu (Gnome), Ubuntu Mate, Xubuntu (Xfce), Lubuntu (LXDE, LXQt), Kubuntu (KDE Plasma), Ubuntu Budgie. Ubuntu Unity, Ubuntu Cinnamon.

Montpellier: Permanence | Wikipermanence, Le lundi 12 janvier 2026 de 19h00 à 22h00.

l'Agenda du Libre - 12 janvier, 2026 - 05:25

Une Wikipermanence est une rencontre physique entre des Wikipédiens chevronnés et de nouveaux ou futurs Wikipédiens qui souhaitent acquérir des connaissances et des conseils sur le fonctionnement de Wikipédia.

Il ne s’agit pas d’une simple rencontre entre Wikipédiens : la Wikipermanence organisée par le groupe local de Montpellier est là pour répondre aux questions, permettre des démonstrations, offrir une aide aux premiers pas et permettre un suivi.

Pour cette soirée, chacun amène ce qu’il veut à manger et à boire pour un repas partagé.

Cette rencontre nous permettra d’aborder les sujets suivants :

Le programme :

  • Information sur la communauté Wikipédia ;
  • Initiation des débutants ;
  • Nous contribuerons sur la mise à jour des différentes pages, sur les Wikipermanences que Montpel’libre organise à Montpellier ;
  • Atelier d’écriture ;
  • Échanger d’expériences ;
  • Proposition d’éditathon ;
  • Contributions libres ;
  • ...et tout simplement, passer un moment convivial.

Si vous avez des propositions, n’hésitez pas à compléter la page dédiée sur Wikipédia.

N’hésitez pas à venir : c’est sans inscription, et vous l’aurez deviné, libre et gratuit !

Wikipédia est une encyclopédie libre rédigée collaborativement par des milliers d’internautes. Mais, saviez-vous que vous pouviez y participer ?

En apportant des connaissances, en créant ou améliorant des articles, en prenant des photos, ou simplement en corrigeant des fautes, vous pouvez contribuer à ce grand projet d’encyclopédie collaborative.

Alors, venez participer aux rendez-vous des Wikipermanences de Montpellier qui auront lieu à l’Atelier de Pigistes, le deuxième lundi de chaque mois, de 19h00 à 22h00.

Cet événement vous est proposé dans le cadre du partenariat qui lie le Club de la Presse, Wikimédia France, Wikimedia Foundation, Wikimedia Education et Montpel’libre.

Inscription | GPS 43.60302/3.89809

https://montpellibre.fr/fiches_activites/Fiche_010_Montpellibre_Permanence_Wikipermanence_Cabalherault.pdf

Chaumont: Permanence Informatique de REVOL, Le samedi 17 janvier 2026 de 09h00 à 12h00.

l'Agenda du Libre - 11 janvier, 2026 - 11:47

REVOL, association engagée dans la promotion des logiciels libres, propose tous les samedis matin, de 9h à 12h, une permanence associative ouverte à toustes, pour se pencher sur les difficultés rencontrées par chacun·e dans son usage de l'outil numérique.

Dans le cadre de la fin de la maintenance de sécurité de windows 10, nous axons ces permanences sur le passage en toute sécurité vers des systèmes d'exploitation libres (Ubuntu, Linux Mint...). Nous proposons un accompagnement complet pour assurer une transition vers le libre la plus sereine possible.

N'hésitez pas à venir nous voir à la Maison des associations de Chaumont, en Haute-Marne. Ce sera l'occasion d'en apprendre plus sur le numérique et de découvrir comment maitriser son ordinateur pour l'utiliser en toute sécurité.

Un monde plus libre, loin des techno-fascistes ça serait

Pau: 25 ans de Wikipédia, Le jeudi 15 janvier 2026 de 12h30 à 18h00.

l'Agenda du Libre - 10 janvier, 2026 - 20:24

Venez fêter les 25 ans de Wikipédia à la Bibliothèque universitaire de l'université de Pau ! Au programme : échange autour de Wikipédia, jeux wikis et visionnage de l'événement international en ligne.

Nouveautés de janvier 2026 de la communauté Scenari

Linuxfr.org - 10 janvier, 2026 - 19:17

Scenari est un ensemble de logiciels open source dédiés à la production collaborative, publication et diffusion de documents multi-support. Vous rédigez une seule fois votre contenu et vous pouvez les générer sous plusieurs formes : site web, PDF, OpenDocument, diaporama, paquet SCORM (Sharable Content Object Reference Model)… Vous ne vous concentrez que sur le contenu et l’outil se charge de créer un rendu professionnel accessible et responsive (qui s’adapte à la taille de l’écran).

À chaque métier/contexte son modèle Scenari :

  • Opale pour la formation 
  • Dokiel pour la documentation 
  • Optim pour les présentations génériques 
  • Topaze pour les études de cas 
  • et bien d’autres…

L’association Scenari te souhaite une belle et heureuse année 2026, pleine de projets Scenari ☘️

« It works on my satellite » ou l'histoire d'un bug dans l'espace

Linuxfr.org - 10 janvier, 2026 - 10:59

Cette dépêche raconte un vieux bug que j’ai eu sur un satellite. L’identification, la reproduction, la correction. C’est le bug qui m’a le plus intéressé/marqué dans ma carrière (jusqu’ici), C’est pourquoi cela pourrait aussi vous intéresser.

L’appel

Il y a bien longtemps, dans une galaxie lointaine. Ah non, pardon. Un long weekend de 14 juillet, sur une plage, je reçois un coup de fil : « Un des satellites a rebooté, à cause d’une erreur logicielle, est-ce que tu es disponible pour venir comprendre ce qu’il s’est passé ? A priori, il fonctionne toujours, mais il est passé tout seul sur le calculateur redondant. »

Quelques mois avant, on avait lancé une première grappe de six satellites ; d’autres lancements sont prévus pour compléter une constellation dans les mois/années à venir. Comme tout marche bien depuis des mois, personne de l’équipe logiciel de bord n’est d’astreinte. Sur ces satellites, j’étais surtout sur la partie validation. En gros, ce jour-là pour moi, ce n’était pas possible, mais j’y suis allé le lendemain, un samedi ou dimanche.

Sommaire L’objectif et les moyens de débug

Si nos managers nous ont appelé, c’est parce quand un satellite bugue en prod (on va dire en vol, plutôt), c’est comme pour n’importe quel autre logiciel, des gens veulent des réponses à des questions comme :

  • pourquoi ?
  • est-ce que c’est grave ?
  • est-ce que ça va se reproduire ?
  • comment on corrige ?

Par contre, les moyens sont potentiellement différents de ce que vous avez dans d’autres environnements (ou pas, j’imagine que ça dépend des gens) Ce qu’on a :

  • le code
  • la doc
  • des bancs de tests (avec le même matériel pour le calculateur)
  • des gens
  • un tout petit peu de contexte logiciel sauvegardé au moment de l’erreur (j’y reviens)
  • la télémétrie avant l’anomalie (tout allait bien)
  • la télémétrie après l’anomalie (tout va bien, mais on est passé du mode matériel 2 au mode 3. En gros c’est le même, sauf qu’on utilise certains équipements “redondants” au lieu du “nominal”, dont le calculateur)

Premier élément, qui a mené au fait que c’est nous (du logiciel) qui avons été appelés, c’est que le matériel qui gère le mode (2 -> 3) peut changer de mode pour plusieurs raisons, mais il sait pourquoi il le fait. Et la raison c’est « le logiciel m’a dit de le faire ». Donc ça vient de nous.

L’analyse

Comme tout va bien, on va regarder le contexte sauvegardé. Ce n’est pas un core dump qu’on peut passer à gdb, mais ça contient quelques infos :

  • le code de l’erreur ILLEGAL CPU INSTRUCTION
  • le Program Counter %pc qui nous donne l’adresse de l’instruction exécutée au moment de l’erreur
  • l’adresse de la prochaine instruction à exécuter %npc (ici c’est l’adresse juste après %pc, rien de surprenant)
  • une copie des registres (bon, on ne va pas en avoir besoin, donc je ne vous fais pas un cours sur SPARC et ses registres tournant, de toute façon j’ai oublié. On pourrait probablement les utiliser pour récupérer partiellement la pile d’appel, on l’a surement fait)
  • la date et l’heure (super info utile. Enfin, ça correspond à notre anomalie, j’imagine que c’est pour ça qu’on l’avait)
  • surement d’autres choses, mais pas utiles pour la suite.

Problème résolu donc ? on est à l’adresse %pc, on l’exécute et le CPU nous dit que l’instruction n’est pas légale. Qu’est-ce qu’il y a ici ? Une instruction légale, quelle que soit la valeur des registres. Pareil pour un peu plus haut et un peu plus bas, rien qui provoque cette erreur. Que s’est-il passé ?

On est dans l’espace, donc l’explication facile (dès qu’on n’explique pas un truc) : l’instruction a dû avoir un Single Event Upset (SEU), un bit flip. Ça a transformé une instruction légale en instruction illégale. C’est simple ? Sauf que non, on est dans l’espace, en conséquence, on a tout un mécanisme de protection contre les SEU. C’est pas infaillible (par exemple si on a deux bits inversés, on ne peut pas corriger) mais ce n’est pas la bonne signature. Si c’était ça, ça dirait DOUBLE EDAC ERROR, pas ILLEGAL CPU INSTRUCTION.

Donc la cause de l’anomalie n’est pas un SEU.

EDAC / Protection contre les SEU

Je suis sûr que vous êtes intéressé, donc je vais vous décrire la protection contre les bit flips. C’est un mix de matériel/logiciel (en plus d’avoir une boite autour qui diminue la probabilité). En mémoire (RAM, ROM) pour 4 octets de données “utiles”, on consomme 5 octets. Le 5ᵉ octet contient un code de contrôle calculé à partir des 4 autres (EDAC). Si un bit change (sur les 5 × 8 = 40 bits), on peut non seulement le détecter mais aussi reconstruire la valeur correcte. Si deux bits changent (ou plus, mais il y a une limite), on peut détecter l’erreur mais pas la corriger (cf: le DOUBLE EDAC ERROR mentionné plus haut)

C’est complètement transparent vu du logiciel (code source, ou assembleur), tout ça est calculé par le matériel. Quand on écrit en mémoire 0x12345678 il calcule le code et écrit 0x12345678XY avec la bonne valeur de X et Y. Quand on lit, pareil, le matériel commence par lire 0x12345678XY, calcule la somme de contrôle sur les 4 octets, si c’est le bon, il nous donne 0x12345678.

Là où ça se complique, c’est quand il y a un changement. Disons qu’on a maintenant 0x02345678XY. (1 --> 0). Il se passe deux choses ici :

  1. le matériel dit au logiciel 0x12345678 (il corrige, mais uniquement la valeur envoyée au software. Pas la valeur enregistrée en mémoire)
  2. il émet un signal SINGLE EDAC ERROR.

C’est là que le logiciel intervient, dans le point 2. Ce signal est lié à une trap qui corrige la mémoire. Schématiquement c’est lié à une fonction qui ressemble à ceci (en assembleur SPARC en vrai, mais j’ai tout oublié)

; adresse vient du contexte, c’est l’adresse qui a été lue en dernier, qui a généré la trap disable_edac_trap: ; Désactiver la trap. Sinon on déclencherait la trap depuis la trap load [adresse], reg ; Lire 4 octets (lecture = correction auto) enable_edac_trap: ; store reg, [adresse] ; Réécrire la valeur corrigée

On lit la valeur, c’est corrigé vu du logiciel par le matériel, on réécrit la valeur, tout est corrigé.

Cette trappe peut être déclenchée par n’importe quelle instruction qui lit de la mémoire (ou par le fait de charger une instruction elle-même depuis la mémoire), et on a même une tâche de fond (plus basse priorité, qui tourne en permanence quand il reste du temps de calcul disponible) qui fait

// en gros. En vrai légèrement plus compliqué void background_task(void) { int address = MEMORY_START; volatile int value; while (1) { value = *address; // s’il y a un bit flip en mémoire, ce sera corrigé par la trap address += 4; if (address >= MEMORY_END) { address = MEMORY_START; } } }

L’idée de cette fonction c’est de lire la mémoire régulièrement. Si on ne faisait pas ça, peut-être que certaines cases mémoires auraient deux bit flips, car pas corrigé après le premier si on ne lit pas la mémoire avant qu’un autre arrive. Ce n’est pas très fréquent d’avoir des bit flips, mais sur les 6 satellites, en cumulé, on en détecte quelques-uns par jour.

L’hypothèse

De retour à la case départ donc. On exécute apparemment l’instruction stockée dans %pc, valide. Et le CPU nous dit qu’elle est invalide, mais clairement, elle est valide. On tourne en rond, on est samedi ou dimanche, fin d’après midi, et le satellite, lui aussi il tourne en rond, sans problèmes. Tout à coup, quelqu’un a l’idée de dire « bon, on ne résoudra pas ça aujourd’hui. On se revoit lundi ? ». On rentre, je bois un verre avec mes colocs (enfin, je suppose. C’était une activité habituelle pour un weekend, ça, au moins)

Retour au bureau, et là (surement plus tard, pas lundi 9h) on a David (un collègue) qui propose : "Comme clairement %pc est valide, est qu’on exécute quelque chose d’invalide, est-ce qu’on est sûr qu’on a bien enregistré %pc?". On vérifie, le code qui fait ça a l’air correct. En plus le contexte général, ce qu’il y a dans les registres est correct. Toujours David "OK, le logiciel est correct, mais est-ce qu’on est sûr que %pc c’est bien toujours l’instruction qu’on exécute ?".

Donc, on vérifie, par acquit de conscience et on remarque que non, pas nécessairement. Si on est dans une trap, le %pc qu’on enregistre pointe vers l’instruction qui a provoqué la trap, pas l’instruction de la trap qu’on exécute. Bon, OK, ça ne nous avance pas nécessairement (mais si j’en parle…)

Nouvelle question donc : Si on est à %pc, quelles sont les traps qui peuvent s’exécuter ? Il y a plein de possibilités, la plupart viennent de causes extérieures (timer matériel, plein d’autres évènements extérieurs) et potentiellement aussi la trap de l’EDAC si on lit une valeur (et l’instruction à %pc lit une valeur).

Donc techniquement, on pourrait aussi être n’importe où dans le code (assembleur) de toutes les traps. Avant on cherchait pourquoi c’était illégal d’exécuter %pc, maintenant on cherche pourquoi ça serait illégal d’exécuter %pc ou n’importe quelle ligne d’une trap active/activable à ce moment-là.

Chez moi, ça marche

Sauf que le code des traps, c’est pas nous qui l’avons écrit. C’est bien du code qui vient de l’entreprise, mais il existe depuis plusieurs années, est utilisé sur le même processeur depuis plusieurs années, et il a plusieurs dizaines d’années de vol (cumulé, en additionnant les satellites) sans problème.

En suivant les principes bien connus du développement logiciel, si on utilise un logiciel sur étagère, pas besoin de le valider (surtout ça coute de l’argent. Cela dit même si on avait essayé, je ne pense pas qu’on aurait trouvé de problème), vu qu’il marche. Par acquit de conscience, on demande, et on nous répond "bah chez nous ça marche" (la légende veut qu’une histoire similaire soit à l’origine de Docker, je ne sais pas si c’est vrai, mais le fameux "it works on my desktop, ship my desktop"…)

Vous avez peut-être lu le titre de l’article, donc vous imaginez où je vais. On se demande « OK, pourquoi ça marche pour eux, et pas pour nous ? » Quelles sont les différences ?

  • on est sur le même CPU/MCU (donc non, c’est pas ça)
  • on a changé de compilateur pour une nouvelle version (mais 1. c’est un compilateur “certifié”, et 2. les traps sont en assembleur…)
  • on est en orbite plus basse, et on a plus de SEU (mais même, quand on regarde leur historique, ils en ont beaucoup aussi, et en cumulé, beaucoup plus. Après… peut-être n’a-t-on pas de chance ?)
L’erreur

Ok, on a changé de compilateur, les traps sont en assembleur, mais le reste du code est dans un langage bien plus courant (non, je rigole, en vrai c’est en Ada…), peut-être que l’interaction entre les traps et le reste du code a changé ?

Pourquoi est-ce qu’on a décidé de changer de compilateur ? Ah pour des histoires de taille mémoire (640 kB should be enough? On avait même plus, genre 2 Mo de ROM, 4 Mo de RAM, large… ou pas). D’ailleurs, au moment du changement, on en a profité pour faire quelques optimisations. Non pas des flags genre -O1 ou -O2. Plus des choses sur le layout mémoire, on a ajouté __attribute__((packed)) qui est supporté, on a un peu changé le linker script…

Par exemple, le packed, ça nous permet de gagner de la place, avant toutes les variables étaient alignées sur une adresse multiple de 4, que ça soit un nombre sur quatre octets, ou un char d’un octet, ils prenaient au moins quatre octets. Maintenant, on a mis les data types multiples de quatre au début de la structure, bien alignés, puis les types qui prenent deux octets, on en met deux dans quatre octets (au lieu d’un et de gacher deux octets pour rien), puis les types de un octect, on en met 4.

D’ailleurs, par exemple, l’instruction à %pc, elle charge une donnée d’un seul octet qui est dans une adresse du type XXX+3, où X est un multiple de 4. C’est pas illégal de faire ça (donc non, toujours pas d’instruction illégale ici)

Après quoi, c’est là où David revient (dans mon souvenir en tout cas, ça venait beaucoup de lui, mais on était beaucoup à échanger sur le sujet). "Ok, %pc lit une donnée non alignée, et il le fait correctement. Mais s’il y a un bit flip, il se passe quoi ?. Bah rien, EDAC détectée, trap, on exécute le code assembleur qui marche sur les autres satellites.

Ah oui, mais non. Si on lit un octet, on peut lire XXX+3, mais si on lit 4 octets, c’est interdit. Il faut lire une adresse multiple de 4. Et donc on a une EDAC, et quand on rentre dans la trap

; adresse == XXX+3 disable_edac_trap: ; load [adresse], reg ; Lire 4 octets enable_edac_trap: ; store reg, [adresse] ;

Ah oui, mais non. load ça lit 4 octets, c’est illégal de lui passer une adresse non multiple de 4, c’est une illegal instruction. Donc ça pourrait être ça :

  1. bit flip sur les quatre octets situés à XXX (l’EDAC est toujours calculé sur 4 octets d’une adresse alignée, même si on lit décalé)
  2. on rentre dans la fonction qui contient %pc
  3. on lit un octet à XXX+3
  4. ça déclenche la trap
  5. la trap essaye de lire 4 octets à XXX+3
  6. ILLEGAL CPU INSTRUCTION, allez en prison sans passer par la case départ
La reproduction

Sur le papier, ça marche. On peut même faire un petit logiciel sur le banc, qui fait juste un load [XXX+3], reg et qui génère une ILLEGAL CPU INSTRUCTION. Mais évidemment nos managers (et notre client) voudraient un peu plus qu’un « sur le papier, c’est ça, trust me bro ».

Donc la question "c’est possible de reproduire exactement comme dans l’espace, plutôt que de juste exécuter une instruction illégale à la main ?". Avec le vrai logiciel qui était dans l’espace, pas un logiciel de test ?

Bien sûr, il suffit d’attendre d’avoir un bit flip, sur le banc, juste au bon endroit, au bon moment. Vous avez combien de siècles devant vous ? Ou alors est-ce qu’on peut mettre le banc à côté d’un réacteur nucléaire ? Ça devrait accélérer les choses (du bon côté du mur de confinement. Ici, “bon”, ça veut dire mauvais pour les humains)

On va quand même regarder si on peut provoquer un bit flip autrement. Bon, a priori, en interne, au logiciel, on ne sait pas comment faire. La doc du processeur (qui vient avec l’edac) ne nous aide pas non plus. On demande à ceux qui nous ont dit que « chez eux, ça marche » qui nous répondent que la trap de l’edac, ils ne l’ont jamais testé, c’est juste une revue de code.

Bon, on envoie quand même un courriel au fabricant du proc, au cas où. Réponse rapide « je reviens vers vous dès que je sais ». Quelques jours (2, 3 semaines ?) plus tard : "Ah oui, c’est possible. D’ailleurs c’est documenté. Page WSYZ sur 5000, il y a **un* paragraphe qui explique comment faire*".

Le TL/DR du paragraphe : Il est possible de désactiver l’EDAC en écriture. Par contre il faut faire des choses spécifiques, donc on a pas de commande prévue pour le faire “simplement” depuis l’extérieur, il faudrait une nouvelle fonction.

void generer_bit_flip(int address, int valeur) { *address = valeur; // écrit la valeur correcte avec l’edac normal manipulate_specific_register_to_disable_edac(); // on a dû écrire la fonction, c’est pas aussi simple *address = valeur ^ 0x00000001; // écrit la valeur avec un bit changé, mais sans changer le checksum enregistré manipulate_specific_register_to_enable_edac(); }

Ça tombe bien, le logiciel qui est dans l’espace a deux fonctionnalités qu’on a testé, mais jamais en vrai avec un truc vraiment utile

  1. on peut patcher la mémoire et écrire ce qu’on veut, où on veut (code, données)
  2. on a plusieurs “fonctions” périodiques qui ne font rien, et qui sont prévues pour être patchées si on veut ajouter quelque chose (via la fonction de patch plus haut)

Donc on peut créer une fonction comme ça (en gros)

void generer_bit_flip(int address, int valeur) { static int actif = TRUE; if (actif) { *address = valeur; // écrit la valeur correcte avec l’edac normal manipulate_specific_register_to_disable_edac(); // ou a dû écrire la fonction, c’est pas aussi simple *address = valeur ^ 0x00000001; // écrit la valeur avec un bit changé, mais sans changer le checksum enregistré manipulate_specific_register_to_enable_edac(); actif = FALSE; // on ne veut le faire qu’une fois } }

Une fois qu’on a la fonction, on la compile. Ensuite on charge le logiciel normal sur le banc, on se met en conditions « avant l’anomalie », on uploade la fonction, on l’active et…

Le banc change de mode, passe du mode 2, au mode 3, sur le calculateur redondant. On vérifie le contexte, même signature que l’anomalie en vol. C’est bon on a fini. (Ouf, mon journal est déjà trop long)

La correction (Over-The-Air, mais sans l’air)

Oui, non, pas exactement. On a une explication, il faut une correction maintenant. Bon, c’est simple. Pour lire une adresse alignée sur 4, il suffit de mettre deux bits à 0. Finalement, voilà le patch

address = address & ~0x3 ; ** Cette ligne est le patch ** disable_edac_trap: ; load [adresse], reg ; enable_edac_trap: ; store reg, [adresse] ;

Oui, c’est un patch d’une instruction dans le binaire. (Techniquement, 5 instructions, parce qu’il faut décaler les 4 instructions existantes de 1, mais on avait des noop en dessous, donc ça rentre)

La dernière question, c’est quelle stratégie d’ update appliquer. On a techniquement quatre familles de satellites à considérer :

  1. les satellites « pré-existants », qui utilisent l’ancien compilateur, sans packed et déjà dans l’espace.
  2. le satellite qui a eu l’anomalie.
  3. les 5 autres satellites de la grappe.
  4. les futurs satellites, non lancés.

Ce qui a été décidé : La première catégorie : Techniquement, on pourrait discuter du fait qu’il y a un bug ou non. Mais même si on considère qu’il y a un bug, il ne peut pas être déclenché. Donc on ne touche à rien. La catégorie 4, c’est facile. Ils sont au sol, on fait une nouvelle version complète du logiciel, on reflashe la rom en entier, et on vérifie.

Il reste les deux autres catégories. Bon la seule différence, c’est qu’un, toujours en mode 3, tourne pour l’instant sur le calculateur redondant (on peut revenir en mode 2, manuellement, si on veut). Donc on décide « on va faire la même chose », et on va corriger le problème (on aurait pu ne rien faire et dire « bah, si ça arrive, on connaît et on revient à chaque fois manuellement en mode 2 »)

Là encore, même si on corrige, on a plusieurs choix :

  1. Mettre à jour la ROM. En fait non, les ROM, parce que chaque calculateur a la sienne. Et le nominal ne peut pas écrire la ROM du redondant, et inversement. (Dès lors, si on veut patcher, qu’est-ce qu’on patche ? Le deux ROM ? Faut-il reconfigurer à la main pour rebooter sur le redondant ?)
  2. utiliser un mécanisme prévu pour « patcher, mais sans patcher la ROM ».

La solution 2, retenue, c’est un mécanisme (déjà dans le logiciel) qui permet de mettre les infos dans une autre mémoire (partagée par les deux calculateurs). Au boot, la ROM est copiée dans la RAM (on exécute le code depuis la RAM), et « avant de démarrer » on vient regarder dans cette table, si l’on doit patcher la RAM. Cela donne quelque chose comme :

ROM (logiciel original) --> Copie vers la RAM --> RAM (logiciel original) --> fonction de patch au boot, vient modifier la RAM --> RAM (trap corrigée) --> boot du logiciel.

Conclusion

Qu’est-ce que je retiens principalement ?

  • quand on me dit que du code fonctionne, donc qu’il est correct… j’ai un doute
  • Ce n’est pas parce que la doc explique quelque chose qu’on peut le trouver. Surtout quand elle fait 5000 pages… Il ne faut pas hésiter à demander

Voila, en quelques pages, une vieille histoire qui m’a marqué. Je suis probablement une des personnes qui a participé à un des patchs le plus haut du monde (plus de 1 000 km d’altitude)

Bon en vrai, la NASA fait des mises à jour logicielles sur des rovers sur Mars, donc c’est clairement pas le record mais c’est pas trop mal (ils ont même peut-être des mises à jour sur leurs sondes plus loin de la terre)

Note : cette histoire date maintenant d’il y a plus de dix ans. Il y a donc forcément des simplifications, des imprécisions, et probablement des erreurs. Aucun satellite n’a été maltraité pendant cette enquête. Il y en a bien un qui est tombé à terre, mais ça c’était avant le lancement.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Montpellier: Cérémonie | Vœux et galette de Montpel'libre, Le lundi 12 janvier 2026 de 19h00 à 22h00.

l'Agenda du Libre - 10 janvier, 2026 - 10:29

Cérémonie | Vœux et galette de Montpel'libre
Lundi 12 janvier 2026 de 19h00 à 22h00
Atelier des Pigistes, 171 bis, rue Frimaire, 34000 Montpellier
Membres, Adhérents, Participants, Curieux, Associations, Entreprises, Partenaires... Montpel'libre vous invite à partager la galette et le royaume.
Inscriptions nécessaires, places limitées | Repas partagé | GPS 43.60305/3.89786

Pour bien commencer l’année et profiter de ces moments tellement joyeux, Montpel’libre vous invite à un instant convivial de partage autour de la galette, royaume, crêpes... et quelques boissons.
...Et bien sûr dans la bonne humeur.

Membres, Adhérents, Participants, Curieux, Associations, Entreprises, Partenaires... Montpel'libre vous invite à partager la galette et le royaume lors de cet instant de convivialité.

Tout comme l’esprit des Logiciels Libres, les recettes de la galette, du royaume et des crêpes vous seront communiquées.

Entrée libre et gratuite sur inscription. Une simple adhésion à l’association est possible. Rejoindre le groupe Montpel’libre sur Telegram S’inscrire à l’Infolettre de Montpel’libre.

Tramway lignes 1 et 3, arrêts Port-Marianne et Rives du Lez
GPS Latitude : 43.603095 | Longitude : 3.898166
Sur inscription | GPS 43.60859/3.89329

Ivry sur Seine: Cours de l'Ecole du Logiciel Libre, Le samedi 10 janvier 2026 de 10h30 à 18h30.

l'Agenda du Libre - 9 janvier, 2026 - 22:17
Présentation de l'E2L Quel est le rôle de l'école du logiciel libre?

Tout d'abord, ce n'est pas une école comme les autres. Elle n'a pas d'établissement fixe, pas de cours de récréation, pas de carte d'étudiant, ni de diplôme de fin d'année.

Comme toutes les écoles, son rôle est d'apprendre à ses élèves les logiciels libres, c'est-à-dire:

  • comment en trouver de bons parmi les nombreux sites qui en proposent,
  • comment en prendre possession en fonction des licences,
  • comment les installer en fonction de ses besoins,
  • comment les tester et les utiliser,
  • comment en comprendre le fonctionnement pour ensuite les modifier,
  • comment écrire ses propres logiciels libres.

En fait, l'école du logiciel libre est une université populaire, comme celles qui ont vu le jour en France à partir du 19ème siècle, et dont le but est de transmettre des connaissances théoriques ou pratiques à tous ceux qui le souhaitent. Et pour atteindre ce but, sa forme juridique est de type "association à but non lucratif".

Comment fonctionne l'école?

Cette école étant une association, elle possède, comme toutes les autres, un bureau, élu chaque année en assemblée générale, pour l'administrer. Mais elle a aussi des responsables pédagogiques dont le rôle est essentiel car ce sont eux qui établissent les programmes des cours en fonction des souhaits des adhérents, valident les candidatures des enseignants et affectent les sessions.

Les membres du bureau et les responsables pédagogiques forment "l'encadrement de l'école". Tous les membres "encadrants" doivent être membres de l'association.

Les locaux où se déroulent les cours seront ceux que l'on veut bien nous prêter: une salle des fêtes, un théâtre, une salle de réunion publique, un amphi dans une école publique, ou autre.

Les thèmes des cours sont définis par les adhérents en fonction de leurs envies, de leurs besoins. Les cours sont ensuite décidés par les responsables pédagogiques de l'école en fonction des enseignants disponibles.

Afin de permettre au plus grand nombre de participer et d'assister aux cours, les sessions se tiennent essentiellement le samedi. Une première, sous forme d'atelier public, de 10h30 à 13h, et une autre, sous forme de cours, de 14h30 à 18h30.

Programme détaillé sur le site http://e2li.org

Maîtriser l'informatique grâce aux logiciels libres

Transcriptions - 9 janvier, 2026 - 17:44

Envie de vous sentir plus à l'aise devant un écran ? Envie d'aider votre entourage à surmonter la fracture numérique ? Vous êtes au bon endroit ! Ensemble, partons à l'aventure pour explorer l'univers de l'informatique. Aidés par les logiciels libres, nous découvrirons comment seller notre monture numérique, comment naviguer sur un web déchaîné, comment transformer nos idées en données, comment communiquer sans entraves ou même comment trouver des magiciens de la technique ! Je ne vous (…)

- Transcriptions / , , , , ,
Syndicate content